﻿
<h1>About Go 101</h1>

<p>
I feel it is hard to describe the contents in this article
in the general description manner.
So this article will use the interview manner to make descriptions instead.
</p>

<h3>Hi Tapir, when and why did you plan to write this book?</h3>

<p>
At about July 2016, after (not very intensively) using Go for two years,
I felt that Go is a simple language and I had mastered Go programming.
At that time, I had collected many details in Go programming.
I thought I can archive these details into a book.
I thought it should be an easy job.
</p>

<p>
I was wrong. I was overconfident.
In trying to make explanations for some details,
I found I couldn't explain them clearly.
With more and more confusions being gathered,
I felt my Go knowledge was so limited that I was still a newbie Go programmer.
</p>

<p>
I gave up writing that book.
</p>

<h3>Gave up? Isn't this book almost finished now?</h3>

<p>
It was that book being cancelled, not the book <b><i>Go 101</i></b>.
I eventually cleared almost all the confusions by reading many official
Go documentation and all kinds of Go articles on Internet,
and by finding answers from some Go forums and the Go project issue tracker.
</p>

<p>
I spent about one year clearing the confusions.
During the period, from time to time,
once I had cleared most confusions on a topic
and regained the confidence on explaining that topic,
I wrote one blog article for that topic.
In the end, I had written about twenty Go articles.
And I had collected more Go details than before.
It was the time to restart the plan of writing a Go book.
</p>

<p>
I wrote another ten basic tutorial articles and twenty more articles
on all kinds of other Go topics.
So now <i>Go 101</i> has about 50 articles.
</p>

<h3>What were your ever confusions?</h3>

<p>
Some of the confusions were a few syntax and semantics design details,
some of them involved values of certain kinds of types
(mainly slices, interfaces and channels),
and a few of them were related to standard package APIs.
</p>

<h3>What are the causes of your ever confusions do you think?</h3>

<p>
Thinking Go is easy to master is considered harmful.
Holding such opinion will make you understand Go shallowly and prevent you from mastering Go.
</p>

<p>
Go is a feature rich language.
Its syntax set is surely not large, but we also can't say it is small.
Some syntax and semantics designs in Go are straightforward,
some are a little counter-intuitive or inconsistent with others.
There are several trade-offs in Go syntax and semantics designs.
A programmer needs certain Go programming experiences to comprehend the trade-offs.
</p>

<p>
Go provides several first-citizen non-essential kinds of types.
Some encapsulations are made in implementing these types
to hide the internal structures of these types.
On one hand, the encapsulations bring much convenience to Go programming.
On the other hand, the encapsulations make some obstacles to
understand the behaviors of values of these types more deeply.
</p>

<p>
Many official and unofficial Go tutorials are very simple
and only cover the general use cases by ignoring many details.
This may be good to encourage new Go programmers to learn and use Go.
On the other hand, this also makes many Go programmers overconfident
on the extent of their Go knowledge.
</p>

<p>
Several functions and types declared in some standard packages
are not got detailed explanations. This is understandable,
for many details are so subtle that it is hard
to find proper wordings to explain them clearly.
Saying a few accurate words is better than says some lots of words with inaccuracies.
But this really leaves some confusions for the package users.
</p>

<h3>So do you think simplicity is not a selling point of Go?</h3>

<p>
I think, at least, simplicity is not a main selling point of Go.
After all, there are several other languages simpler than Go.
On the other hand, Go, as a feature rich language, is also not a complicated language.
A new Go programmer with right attitudes can master Go programming in one year.
</p>

<h3>Then what are the selling points of Go do you think?</h3>

<p>
Personally, I think the fact that, as a static language, Go is flexible
as many dynamic script languages is the main selling point of Go language.
</p>

<p>
Memory saving, fast program warming-up and fast code execution speed combined
is another main selling point of Go.
Although this is a common selling point of many C family languages.
But for web development area, seldom languages own the three characteristics at the same time.
In fact, this is the reason why I switched to Go from Java for web development.
</p>

<p>
Built-in concurrent programming support is also a selling point of Go,
though personally I don't think it is the main selling point of Go.
</p>

<p>
Great code readability is another important selling point of Go.
I feel readability is the most important factor considered in designing Go.
</p>

<p>
Great cross-platform support is also a selling point of Go,
though this selling point is not much unique nowadays.
</p>

<p>
A stable core design and development team and an active community together
can also be viewed as a selling point of Go.
</p>

<h3>What does Go 101 do to clear these confusions?</h3>

<div>
<i>Go 101</i> tries to clear many confusions by doing the followings.
<ol>
<li>
	Emphasizes on basic concepts and terminologies.
	Without understanding these basic concepts and terminologies,
	it is hard to fully understand many rules and high level concepts.
</li>
<li>
	Adds the <b><i>value part</i></b> terminology and use one special article
	to explain value parts. This article uncovers the underlying structures
	of some kinds of types, so that Go programmers could understand
	Go values of those types more deeply.
	I think knowing a little possible underlying implementations is very
	helpful to clear some confusions about all kinds of Go values.
</li>
<li>
	Explains memory blocks in detail. Knowing the relations between
	Go values and memory blocks is very helpful to understand
	how a garbage collector works and how to avoid memory leaking.
</li>
<li>
	Views interface values as boxes for wrapping non-interface values.
	I found thinking interface values as value boxes is very helpful
	to clear many interface related confusions.
</li>
<li>
	Makes several summary articles and special topic articles by
	aggregating many knowledge points and details, which would save
	Go programmers much learning time.
</li>
</ol>
</div>




